A service is an abstract definition of a computing resource within an application which can be scaled or replacedindependently from other components. Services are backed by a set of containers, run by the platformaccording to replication requirements and placement constraints. As services are backed by containers, they are definedby a Docker image and set of runtime arguments. All containers within a service are identically created with thesearguments.

A Compose file must declare a services top-level element as a map whose keys are string representations of service names,and whose values are service definitions. A service definition contains the configuration that is applied to eachservice container.

Each service may also include a build section, which defines how to create the Docker image for the service.Compose supports building docker images using this service definition. If not used, the build section is ignored and the Compose file is still considered valid. Build support is an optional aspect of the Compose Specification, and isdescribed in detail in theCompose Build Specification documentation.

Each service defines runtime constraints and requirements to run its containers. The deploy section groupsthese constraints and allows the platform to adjust the deployment strategy to best match containers' needs withavailable resources. Deploy support is an optional aspect of the Compose Specification, and isdescribed in detail in theCompose Deploy Specification documentation.If not implemented the deploy section is ignored and the Compose file is still considered valid.

The following example demonstrates how to define two simple services, set their images, map ports, and configure basic environment variables using Docker Compose.

In the following example, the proxy service uses the Nginx image, mounts a local Nginx configuration file into the container, exposes port 80 and depends on the backend service.

The backend service builds an image from the Dockerfile located in the backend directory that is set to build at stage builder.

For more example Compose files, explore theAwesome Compose samples.

annotations defines annotations for the container. annotations can use either an array or a map.

When attach is defined and set to false Compose does not collect service logs,until you explicitly request it to.

The default service configuration is attach: true.

build specifies the build configuration for creating a container image from source, as defined in theCompose Build Specification.

blkio_config defines a set of configuration options to set block IO limits for a service.

Set a limit in bytes per second for read / write operations on a given device.Each item in the list must have two keys:

Set a limit in operations per second for read / write operations on a given device.Each item in the list must have two keys:

Modify the proportion of bandwidth allocated to a service relative to other services.Takes an integer value between 10 and 1000, with 500 being the default.

Fine-tune bandwidth allocation by device. Each item in the list must have two keys:

cpu_count defines the number of usable CPUs for service container.

cpu_percent defines the usable percentage of the available CPUs.

cpu_shares defines, as integer value, a service container's relative CPU weight versus other containers.

cpu_period configures CPU CFS (Completely Fair Scheduler) period when a platform is basedon Linux kernel.

cpu_quota configures CPU CFS (Completely Fair Scheduler) quota when a platform is basedon Linux kernel.

cpu_rt_runtime configures CPU allocation parameters for platforms with support for realtime scheduler. It can be eitheran integer value using microseconds as unit or aduration.

cpu_rt_period configures CPU allocation parameters for platforms with support for realtime scheduler. It can be eitheran integer value using microseconds as unit or aduration.

cpus define the number of (potentially virtual) CPUs to allocate to service containers. This is a fractional number.0.000 means no limit.

When set, cpus must be consistent with the cpus attribute in theDeploy Specification.

cpuset defines the explicit CPUs in which to allow execution. Can be a range 0-3 or a list 0,1

cap_add specifies additional containercapabilitiesas strings.

cap_drop specifies containercapabilities to dropas strings.

cgroup specifies the cgroup namespace to join. When unset, it is the container runtime's decision toselect which cgroup namespace to use, if supported.

cgroup_parent specifies an optional parentcgroup for the container.

command overrides the default command declared by the container image, for example by Dockerfile's CMD.

The value can also be a list, in a manner similar toDockerfile:

If the value is null, the default command from the image is used.

If the value is [] (empty list) or '' (empty string), the default command declared by the image is ignored,i.e. overridden to be empty.

Configs allow services to adapt their behaviour without the need to rebuild a Docker image.Services can only access configs when explicitly granted by the configs attribute. Two different syntax variants are supported.

Compose reports an error if config doesn't exist on the platform or isn't defined in theconfigs top-level element in the Compose file.

There are two syntaxes defined for configs: a short syntax and a long syntax.

You can grant a service access to multiple configs, and you can mix long and short syntax.

The short syntax variant only specifies the config name. This grants thecontainer access to the config and mounts it as files into a service’s container’s filesystem. The location of the mount point within the container defaults to / in Linux containers, and C:\ in Windows containers.

The following example uses the short syntax to grant the redis serviceaccess to the my_config and my_other_config configs. The value ofmy_config is set to the contents of the file ./my_config.txt, andmy_other_config is defined as an external resource, which means that it hasalready been defined in the platform. If the external config does not exist,the deployment fails.

The long syntax provides more granularity in how the config is created within the service's task containers.

The following example sets the name of my_config to redis_config within thecontainer, sets the mode to 0440 (group-readable) and sets the user and groupto 103. The redis service does not have access to the my_other_configconfig.

container_name is a string that specifies a custom container name, rather than a name generated by default.

Compose does not scale a service beyond one container if the Compose file specifies acontainer_name. Attempting to do so results in an error.

container_name follows the regex format of [a-zA-Z0-9][a-zA-Z0-9_.-]+

credential_spec configures the credential spec for a managed service account.

If you have services that use Windows containers, you can use file: andregistry: protocols for credential_spec. Compose also supports additionalprotocols for custom use-cases.

The credential_spec must be in the format file:// or registry://.

When using registry:, the credential spec is read from the Windows registry onthe daemon's host. A registry value with the given name must be located in:

The following example loads the credential spec from a value named my-credential-specin the registry:

When configuring a gMSA credential spec for a service, you only needto specify a credential spec with config, as shown in the following example:

With the depends_on attribute, you can control the order of service startup and shutdown. It is useful if services are closely coupled, and the startup sequence impacts the application's functionality.

The short syntax variant only specifies service names of the dependencies.Service dependencies cause the following behaviors:

Compose creates services in dependency order. In the followingexample, db and redis are created before web.

Compose removes services in dependency order. In the followingexample, web is removed before db and redis.

Simple example:

Compose guarantees dependency services have been started beforestarting a dependent service.Compose waits for dependency services to be "ready" beforestarting a dependent service.

The long form syntax enables the configuration of additional fields that can't beexpressed in the short form.

restart: When set to true Compose restarts this service after it updates the dependency service.This applies to an explicit restart controlled by a Compose operation, and excludes automated restart by the container runtimeafter the container dies. Introduced in Docker Compose version2.17.0.

condition: Sets the condition under which dependency is considered satisfied

required: When set to false Compose only warns you when the dependency service isn't started or available. If it's not definedthe default value of required is true. Introduced in Docker Compose version2.20.0.

Service dependencies cause the following behaviors:

Compose creates services in dependency order. In the followingexample, db and redis are created before web.

Compose waits for healthchecks to pass on dependenciesmarked with service_healthy. In the following example, db is expected tobe "healthy" before web is created.

Compose removes services in dependency order. In the followingexample, web is removed before db and redis.

Compose guarantees dependency services are started beforestarting a dependent service.Compose guarantees dependency services marked withservice_healthy are "healthy" before starting a dependent service.

deploy specifies the configuration for the deployment and lifecycle of services, as definedin the Compose Deploy Specification.

develop specifies the development configuration for maintaining a container in sync with source, as defined in theDevelopment Section.

device_cgroup_rules defines a list of device cgroup rules for this container.The format is the same format the Linux kernel specifies in theControl GroupsDevice Whitelist Controller.

devices defines a list of device mappings for created containers in the form ofHOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS].

dns defines custom DNS servers to set on the container network interface configuration. It can be a single value or a list.

dns_opt list custom DNS options to be passed to the container’s DNS resolver (/etc/resolv.conf file on Linux).

dns_search defines custom DNS search domains to set on container network interface configuration. It can be a single value or a list.

domainname declares a custom domain name to use for the service container. It must be a valid RFC 1123 hostname.

driver_opts specifies a list of options as key-value pairs to pass to the driver. These options aredriver-dependent.

Consult thenetwork drivers documentation for more information.

entrypoint declares the default entrypoint for the service container.This overrides the ENTRYPOINT instruction from the service's Dockerfile.

If entrypoint is non-null, Compose ignores any default command from the image, for example the CMDinstruction in the Dockerfile.

See alsocommand to set or override the default command to be executed by the entrypoint process.

In its short form, the value can be defined as a string:

Alternatively, the value can also be a list, in a manner similar to theDockerfile:

If the value is null, the default entrypoint from the image is used.

If the value is [] (empty list) or '' (empty string), the default entrypoint declared by the image is ignored,i.e. overridden to be empty.

The env_file attribute is used to specify one or more files that contain environment variables to be passed to the containers.

env_file can also be a list. The files in the list are processed from the top down. For the same variablespecified in two env files, the value from the last file in the list stands.

List elements can also be declared as a mapping, which then lets you set an additionalattribute required. This defaults to true. When required is set to false and the .env file is missing,Compose silently ignores the entry.

required attribute is available with Docker Compose version 2.24.0 or later.

Relative path are resolved from the Compose file's parent folder. As absolute paths prevent the Composefile from being portable, Compose warns you when such a path is used to set env_file.

Environment variables declared in theenvironment section override these values. This holds true even if those values areempty or undefined.

Each line in an .env file must be in VAR[=[VAL]] format. The following syntax rules apply:

VAL may be omitted, in such cases the variable value is an empty string.=VAL may be omitted, in such cases the variable is unset.

The environment attribute defines environment variables set in the container. environment can use either an array or amap. Any boolean values; true, false, yes, no, should be enclosed in quotes to ensurethey are not converted to True or False by the YAML parser.

Environment variables can be declared by a single key (no value to equals sign). In this case Composerelies on you to resolve the value. If the value is not resolved, the variableis unset and is removed from the service container environment.

Map syntax:

Array syntax:

When both env_file and environment are set for a service, values set by environment have precedence.

expose defines the (incoming) port or a range of ports that Compose exposes from the container. These ports must beaccessible to linked services and should not be published to the host machine. Only the internal containerports can be specified.

Syntax is /[] or /[] for a port range.When not explicitly set, tcp protocol is used.

Note

If the Dockerfile for the image already exposes ports, it is visible to other containers on the network even if expose is not set in your Compose file.

extends lets you share common configurations among different files, or even different projects entirely. With extends you can define a common set of service options in one place and refer to it from anywhere. You can refer to another Compose file and select a service you want to also use in your own application, with the ability to override some attributes for your own needs.

You can use extends on any service together with other configuration keys. The extends value must be a mappingdefined with a required service and an optional file key.

When a service uses extends, it can also specify dependencies on other resources, an explicit volumes declaration for instance. However, it's important to note that extends does not automatically incorporate the target volume definition into the extending Compose file. Instead, you are responsible for ensuring that an equivalent resource exists for the service being extended to maintain consistency. Docker Compose verifies that a resource with the referenced ID is present within the Compose model.

Dependencies on other resources in an extends target can be:

Circular references with extends are not supported, Compose returns an error when one is detected.

file value can be:

A service denoted by service must be present in the identified referenced Compose file.Compose returns an error if:

Two service definitions, the main one in the current Compose file and the referenced onespecified by extends, are merged in the following way:

The following keys should be treated as mappings: annotations, build.args, build.labels,build.extra_hosts, deploy.labels, deploy.update_config, deploy.rollback_config,deploy.restart_policy, deploy.resources.limits, environment, healthcheck,labels, logging.options, sysctls, storage_opt, extra_hosts, ulimits.

One exception that applies to healthcheck is that the main mapping cannot specifydisable: true unless the referenced mapping also specifies disable: true. Compose returns an error in this case.

For example, the input below:

Produces the following configuration for the cli service. The same output isproduced if array syntax is used.

Items under blkio_config.device_read_bps, blkio_config.device_read_iops,blkio_config.device_write_bps, blkio_config.device_write_iops, devices andvolumes are also treated as mappings where key is the target path inside thecontainer.

For example, the input below:

Produces the following configuration for the cli service. Note that the mounted pathnow points to the new volume name and ro flag was applied.

If the referenced service definition contains extends mapping, the items under itare simply copied into the new merged definition. The merging process is then kickedoff again until no extends keys are remaining.

For example, the input below:

Produces the following configuration for the cli service. Here, cli servicesgets user key from common service, which in turn gets this key from baseservice.

The following keys should be treated as sequences: cap_add, cap_drop, configs,deploy.placement.constraints, deploy.placement.preferences,deploy.reservations.generic_resources, device_cgroup_rules, expose,external_links, ports, secrets, security_opt.Any duplicates resulting from the merge are removed so that the sequence onlycontains unique elements.

For example, the input below:

Produces the following configuration for the cli service.

In case list syntax is used, the following keys should also be treated as sequences:dns, dns_search, env_file, tmpfs. Unlike sequence fields mentioned above,duplicates resulting from the merge are not removed.

Any other allowed keys in the service definition should be treated as scalars.

external_links link service containers to services managed outside of your Compose application.external_links define the name of an existing service to retrieve using the platform lookup mechanism.An alias of the form SERVICE:ALIAS can be specified.

extra_hosts adds hostname mappings to the container network interface configuration (/etc/hosts for Linux).

Short syntax uses plain strings in a list. Values must set hostname and IP address for additional hosts in the form of HOSTNAME=IP.

IPv6 addresses can be enclosed in square brackets, for example:

The separator = is preferred, but : can also be used. Introduced in Docker Compose version2.24.1. For example:

Alternatively, extra_hosts can be set as a mapping between hostname(s) and IP(s)

Compose creates a matching entry with the IP address and hostname in the container's networkconfiguration, which means for Linux /etc/hosts get extra lines:

group_add specifies additional groups, by name or number, which the user inside the container must be a member of.

An example of where this is useful is when multiple containers (running as different users) need to all read or writethe same file on a shared volume. That file can be owned by a group shared by all the containers, and specified ingroup_add.

Running id inside the created container must show that the user belongs to the mail group, which would not havebeen the case if group_add were not declared.

The healthcheck attribute declares a check that's run to determine whether or not the service containers are "healthy". It works in the same way, and has the same default values, as the HEALTHCHECK Dockerfile instructionset by the service's Docker image. Your Compose file can override the values set in the Dockerfile.

For more information on HEALTHCHECK, see theDockerfile reference.

interval, timeout, start_period, and start_interval arespecified as durations. Introduced in Docker Compose version2.20.2

test defines the command Compose runs to check container health. It can beeither a string or a list. If it's a list, the first item must be either NONE, CMD or CMD-SHELL.If it's a string, it's equivalent to specifying CMD-SHELL followed by that string.

Using CMD-SHELL runs the command configured as a string using the container's default shell(/bin/sh for Linux). Both forms below are equivalent:

NONE disables the healthcheck, and is mostly useful to disable the Healthcheck Dockerfile instruction set by the service's Docker image. Alternatively,the healthcheck set by the image can be disabled by setting disable: true:

hostname declares a custom host name to use for the service container. It must be a valid RFC 1123 hostname.

image specifies the image to start the container from. image must follow the Open Container Specificationaddressable image format,as [/][/][:|@].

If the image does not exist on the platform, Compose attempts to pull it based on the pull_policy.If you are also using theCompose Build Specification, there are alternative options for controlling the precedence ofpull over building the image from source, however pulling the image is the default behavior.

image may be omitted from a Compose file as long as a build section is declared. If you are not using the Compose Build Specification, Compose won't work if image is missing from the Compose file.

init runs an init process (PID 1) inside the container that forwards signals and reaps processes.Set this option to true to enable this feature for the service.

The init binary that is used is platform specific.

ipc configures the IPC isolation mode set by the service container.

isolation specifies a container’s isolation technology. Supported values are platform specific.

labels add metadata to containers. You can use either an array or a map.

It's recommended that you use reverse-DNS notation to prevent your labels from conflicting withthose used by other software.

Compose creates containers with canonical labels:

The com.docker.compose label prefix is reserved. Specifying labels with this prefix in the Compose fileresults in a runtime error.

links defines a network link to containers in another service. Either specify both the service name anda link alias (SERVICE:ALIAS), or just the service name.

Containers for the linked service are reachable at a hostname identical to the alias, or the service nameif no alias is specified.

Links are not required to enable services to communicate. When no specific network configuration is set,any service is able to reach any other service at that service’s name on the default network. If servicesdo declare networks they are attached to, links does not override the network configuration and services notattached to a shared network are not be able to communicate. Compose doesn't warn you about a configuration mismatch.

Links also express implicit dependency between services in the same way asdepends_on, so they determine the order of service startup.

logging defines the logging configuration for the service.

The driver name specifies a logging driver for the service's containers. The default and available valuesare platform specific. Driver specific options can be set with options as key-value pairs.

Available with Docker Compose version 2.24.0 and later.

mac_address sets a MAC address for the service container.

Note

Container runtimes might reject this value (ie. Docker Engine >= v25.0). In that case, you should usenetworks.mac_address instead.

mem_limit configures a limit on the amount of memory a container can allocate, set as a string expressing abyte value.

When set, mem_limit must be consistent with the limits.memory attribute in theDeploy Specification.

mem_reservation configures a reservation on the amount of memory a container can allocate, set as a string expressing abyte value.

When set, mem_reservation must be consistent with the reservations.memory attribute in theDeploy Specification.

mem_swappiness defines as a percentage, a value between 0 and 100, for the host kernel to swap outanonymous memory pages used by a container.

The default value is platform specific.

memswap_limit defines the amount of memory the container is allowed to swap to disk. This is a modifierattribute that only has meaning ifmemory is also set. Using swap lets the container write excessmemory requirements to disk when the container has exhausted all the memory that is available to it.There is a performance penalty for applications that swap memory to disk often.

network_mode sets a service container's network mode.

For more information container networks, see theDocker Engine documentation.

When set, thenetworks attribute is not allowed and Compose rejects anyCompose file containing both attributes.

The networks attribute defines the networks that service containers are attached to, referencing entries under thenetworks top-level element. The networks attribute helps manage the networking aspects of containers, providing control over how services are segmented and interact within the Docker environment. This is used to specify which networks the containers for that service should connect to. This is important for defining how containers communicate with each other and externally.

For more information about the networks top-level element, seeNetworks.

aliases declares alternative hostnames for the service on the network. Other containers on the samenetwork can use either the service name or an alias to connect to one of the service's containers.

Since aliases are network-scoped, the same service can have different aliases on different networks.

Note

A network-wide alias can be shared by multiple containers, and even by multiple services.If it is, then exactly which container the name resolves to is not guaranteed.

In the following example, service frontend is able to reach the backend service atthe hostname backend or database on the back-tier network. The service monitoringis able to reach same backend service at backend or mysql on the admin network.

Specify a static IP address for a service container when joining the network.

The corresponding network configuration in thetop-level networks section must have anipam attribute with subnet configurations covering each static address.

link_local_ips specifies a list of link-local IPs. Link-local IPs are special IPs which belong to a wellknown subnet and are purely managed by the operator, usually dependent on the architecture where they aredeployed.

Example:

mac_address sets the MAC address used by the service container when connecting to this particular network.

priority indicates in which order Compose connects the service’s containers to itsnetworks. If unspecified, the default value is 0.

In the following example, the app service connects to app_net_1 first as it has the highest priority. It then connects to app_net_3, then app_net_2, which uses the default priority value of 0.

If oom_kill_disable is set, Compose configures the platform so it won't kill the container in caseof memory starvation.

oom_score_adj tunes the preference for containers to be killed by platform in case of memory starvation. Value mustbe within -1000,1000 range.

pid sets the PID mode for container created by Compose.Supported values are platform specific.

pids_limit tunes a container’s PIDs limit. Set to -1 for unlimited PIDs.

When set, pids_limit must be consistent with the pids attribute in theDeploy Specification.

platform defines the target platform the containers for the service run on. It uses the os[/arch[/variant]] syntax.

The values of os, arch, and variant must conform to the convention used by theOCI Image Spec.

Compose uses this attribute to determine which version of the image is pulledand/or on which platform the service’s build is performed.

The ports is used to define the port mappings between the host machine and the containers. This is crucial for allowing external access to services running inside containers. It can be defined using short syntax for simple port mapping or long syntax, which includes additional options like protocol type and network mode.

Note

Port mapping must not be used with network_mode: host otherwise a runtime error occurs.

The short syntax is a colon-separated string to set the host IP, host port, and container portin the form:

[HOST:]CONTAINER[/PROTOCOL] where:

If host IP is not set, it binds to all network interfaces. Ports can be either a singlevalue or a range. Host and container must use equivalent ranges.

Either specify both ports (HOST:CONTAINER), or just the container port. In the latter case,the container runtime automatically allocates any unassigned port of the host.

HOST:CONTAINER should always be specified as a (quoted) string, to avoid conflictswithyaml base-60 float.

Examples:

Note

If Host IP mapping is not supported by a container engine, Compose rejectsthe Compose file and ignores the specified host IP.

The long form syntax allows the configuration of additional fields that can't beexpressed in the short form.

post_start defines a sequence of lifecycle hooks to run after a container has started. The exact timing of when the command is run is not guaranteed.

For more information, seeUse lifecycle hooks.

pre_stop defines a sequence of lifecycle hooks to run before the container is stopped. These hooks won't run if the container stops by itself or is terminated suddenly.

Configuration is equivalent to`post_start.

privileged configures the service container to run with elevated privileges. Support and actual impacts are platform specific.

profiles defines a list of named profiles for the service to be enabled under. If unassigned, the service is always started but if assigned, it is only started if the profile is activated.

If present, profiles follow the regex format of [a-zA-Z0-9][a-zA-Z0-9_.-]+.

pull_policy defines the decisions Compose makes when it starts to pull images. Possible values are:

read_only configures the service container to be created with a read-only filesystem.

restart defines the policy that the platform applies on container termination.

You can find more detailed information on restart policies in theRestart Policies (--restart)section of the Docker run reference page.

runtime specifies which runtime to use for the service’s containers.

For example, runtime can be the name ofan implementation of OCI Runtime Spec, such as "runc".

The default is runc. To use a different runtime, seeAlternative runtimes.

scale specifies the default number of containers to deploy for this service.When both are set, scale must be consistent with the replicas attribute in theDeploy Specification.

The secrets attribute grants access to sensitive data defined by the secrets top-level element on a per-service basis. Services can be granted access to multiple secrets.

Two different syntax variants are supported; the short syntax and the long syntax. Long and short syntax for secrets may be used in the same Compose file.

Compose reports an error if the secret doesn't exist on the platform or isn't defined in thesecrets top-level section of the Compose file.

Defining a secret in the top-level secrets must not imply granting any service access to it.Such grant must be explicit within service specification assecrets service element.

The short syntax variant only specifies the secret name. This grants thecontainer access to the secret and mounts it as read-only to /run/secrets/within the container. The source name and destination mountpoint are both setto the secret name.

The following example uses the short syntax to grant the frontend serviceaccess to the server-certificate secret. The value of server-certificate is setto the contents of the file ./server.cert.

The long syntax provides more granularity in how the secret is created withinthe service's containers.

The following example sets the name of the server-certificate secret file to server.certwithin the container, sets the mode to 0440 (group-readable), and sets the user and groupto 103. The value of server-certificate is setto the contents of the file ./server.cert.

security_opt overrides the default labeling scheme for each container.

For further default labeling schemes you can override, seeSecurity configuration.

shm_size configures the size of the shared memory (/dev/shm partition on Linux) allowed by the service container.It's specified as abyte value.

stdin_open configures a service's container to run with an allocated stdin. This is the same as running a container with the-i flag. For more information, seeKeep STDIN open.

Supported values are true or false.

stop_grace_period specifies how long Compose must wait when attempting to stop a container if it doesn'thandle SIGTERM (or whichever stop signal has been specified withstop_signal), before sending SIGKILL. It's specifiedas aduration.

Default value is 10 seconds for the container to exit before sending SIGKILL.

stop_signal defines the signal that Compose uses to stop the service containers.If unset containers are stopped by Compose by sending SIGTERM.

storage_opt defines storage driver options for a service.

sysctls defines kernel parameters to set in the container. sysctls can use either an array or a map.

You can only use sysctls that are namespaced in the kernel. Docker does notsupport changing sysctls inside a container that also modify the host system.For an overview of supported sysctls, refer toconfigure namespaced kernelparameters (sysctls) at runtime.

tmpfs mounts a temporary file system inside the container. It can be a single value or a list.

tty configures a service's container to run with a TTY. This is the same as running a container with the-t or --tty flag. For more information, seeAllocate a pseudo-TTY.

Supported values are true or false.

ulimits overrides the default ulimits for a container. It's specified either as an integer for a single limitor as mapping for soft/hard limits.

user overrides the user used to run the container process. The default is set by the image (i.e. Dockerfile USER). If it's not set, then root.

userns_mode sets the user namespace for the service. Supported values are platform specific and may dependon platform configuration.

uts configures the UTS namespace mode set for the service container. When unspecifiedit is the runtime's decision to assign a UTS namespace, if supported. Available values are:

The volumes attribute define mount host paths or named volumes that are accessible by service containers. You can use volumes to define multiple types of mounts; volume, bind, tmpfs, or npipe.

If the mount is a host path and is only used by a single service, it can be declared as part of the servicedefinition. To reuse a volume across multiple services, a namedvolume must be declared in the volumes top-level element.

The following example shows a named volume (db-data) being used by the backend service,and a bind mount defined for a single service.

For more information about the volumes top-level element, seeVolumes.

The short syntax uses a single string with colon-separated values to specify a volume mount(VOLUME:CONTAINER_PATH), or an access mode (VOLUME:CONTAINER_PATH:ACCESS_MODE).

Note

The SELinux re-labeling bind mount option is ignored on platforms without SELinux.

Note

Relative host paths are only supported by Compose that deploy to alocal container runtime. This is because the relative path is resolved from the Compose file’s parentdirectory which is only applicable in the local case. When Compose deploys to a non-localplatform it rejects Compose files which use relative host paths with an error. To avoid ambiguitieswith named volumes, relative paths should always begin with . or ...

The long form syntax allows the configuration of additional fields that can't beexpressed in the short form.

Tip

Working with large repositories or monorepos, or with virtual file systems that are no longer scaling with your codebase?Compose now takes advantage ofSynchronized file shares and automatically creates file shares for bind mounts.Ensure you're signed in to Docker with a paid subscription and have enabled both Access experimental features and Manage Synchronized file shares with Compose in Docker Desktop's settings.

volumes_from mounts all of the volumes from another service or container. You can optionally specifyread-only access ro or read-write rw. If no access level is specified, then read-write access is used.

You can also mount volumes from a container that is not managed by Compose by using the container: prefix.

working_dir overrides the container's working directory which is specified by the image, for example Dockerfile's WORKDIR.